1. Field of the Invention
This invention relates generally to software testing, and more particularly to public application program interface (API) test coverage in a Java programming environment.
2. Description of the Related Art
Today's world of computer programming offers many high-level programming languages. Java, for example, has achieved widespread use in a relatively short period of time and is largely attributed with the ubiquitous success of the Internet. The popularity of Java is due, at least in part, to its platform independence, object orientation and dynamic nature. In addition, Java removes many of the tedious and error-prone tasks that must be performed by an application programmer, including memory management and cross-platform porting. In this manner, the Java programmer can better focus on design and functionality issues.
One particular Java environment is the Java 2 platform, Enterprise Edition (J2EE), which facilitates building Web-based and enterprise applications. J2EE defines a standard for developing multitier enterprise applications, which simplifies enterprise applications by basing them on standardized, modular components, providing a complete set of services to those components, and handling many details of application behavior automatically, without complex programming.
J2EE takes advantage of many features of the Java 2 Platform, Standard Edition, such as “Write Once, Run Anywhere™” portability, JDBC™ application program interface (API) for database access, CORBA technology for interaction with existing enterprise resources, and a security model that protects data even in Internet applications. Building on this base, Java 2 Enterprise Edition adds full support for Enterprise JavaBeans™ components, Java Servlets API, JavaServer Pages™ and XML technology. The J2EE standard includes complete specifications and compliance tests to ensure portability of applications across the wide range of existing enterprise systems capable of supporting J2EE.
Broadly speaking, J2EE can be conceptually divided into two areas, namely, application servers and applications. FIG. 1 is a logical diagram showing a conventional J2EE space 100. The J2EE space 100 includes applications servers 108a–108c, and applications 106a–106b, which execute on the applications servers 108a–108c. The application servers 108a–108c are essentially large blocks of software developed by individual developers that provide services for applications written to execute in their environment, thus simplifying application development. The applications 106a–106b are smaller, less complex software applications that execute within the application servers 108a–108c. Since many of the services needed by the applications 106a–106b are available through the application servers 108a–108c, application development is simplified and the application code can be less complex.
Further, the applications servers 108a–108c theoretically provide portability to the applications 106a–106b, which allows any application 106a–106b to execute on any application server 108a–108c. For example, a properly developed application 106a should be capable of executing on both application servers 108a and 108b with little or no change in the code of application 106a. However, not all applications 106a–106b are developed to provide adequate portability.
FIG. 2 is a logical diagram showing an exemplary prior art J2EE application 106. The exemplary prior art J2EE application 106 includes a web application 206 in communication with a remote browser 208, and an Enterprise Java Bean (EJB) bundle 200 in communication with an application client 210, which can also be remotely located. The web application 206 facilitates communication via the Internet with a browser 208. Typically, the browser 208 sends hypertext transfer protocol (HTTP) based data to the web application 206, which responds with hypertext markup language (HTML). In this manner, the web application 206 can provide static content such as standard web pages. In addition, the web application 206 can provide dynamic content, such as a bank statement, using Java servlets and JavaServer pages (JSPs).
The J2EE application 106 further includes an EJB bundle 200, which comprises a plurality of EJBs 202. The J2EE specifications define how applications should be written for the J2EE environment. Thus the specifications provide the contract between the applications and the J2EE platform. One aspect of the J2EE specification is the EJB 2.0 Container Managed Persistence (CMP). The EJB 2.0 specification defines a contract between an entity bean, its container and the persistence manager for the management of persistent state and relationships for the entity beans. For a complete specification of CMP, refer to the EJB 2.0 specification published by Sun Microsystems, Inc., which is incorporated by reference herein in its entirety.
According to the EJB programming model, a bean provider develops a set of EJBs 202 for an application and specifies the relationships between these objects. More specifically, each EJB 202 includes a public application program interface (API) 204, which provides an interface to that EJB 202. Each API 204 is an interface comprising a plurality of methods that can be called by an application client 210 to interface with the particular EJB 202. For example, an EJB for customer service may include within the API a method to determine an individual's credit limit. The application client 210 can then call the method using appropriate parameters, and the EJB 202 will process the method call. In addition to the application client 210, other EJBs 202 can interface with a particular EJB 202 via its public API 204, as can web applications 206.
As mentioned above, application servers are developed by individual application server developers, such as International Business Machines (IBM) and Oracle. As such, many different application servers are currently available for use in executing J2EE application. Although, all application servers are designed to allow portability of J2EE applications, many application servers include special services that are not available on other application servers. As a result, J2EE applications that are designed to utilize the special services of a particular application server generally lose portability, since the special service may not be available on a different application server. Thus, it is desirable to know the portability of a particular J2EE application so that a user can determine the extent to which the product is tied to a particular application server. However, it is difficult to ascertain the portability of a product in a standard manner that can be independently verified.
In view of the forgoing, there is a need for methods that can determine the portability of a particular J2EE application in a standard manner that can be independently verified. The methods should be automated to reduce operator error, and allow portability testing without regard to the actual functionality of the J2EE application.